Methods, systems, and computer readable media for selecting a codec pair based on network conditions

ABSTRACT

A method for selecting a codec pair includes obtaining a first performance metric indicating a condition of a first network connected to the network node via a first communication interface, the first network including a first endpoint. A second performance metric indicating a condition of a second network connected to the network node via a second communication interface is obtained. The second network includes a second endpoint. A codec selection model is generated or updated based on the first and second performance metrics. A first codec is selected from a plurality of codecs compatible with the first endpoint based on the codec selection model. A second codec is selected from a plurality of codecs compatible with the second endpoint based on the codec selection model. The first and second codecs are used to communicate a portion of a communication session between the first endpoint and the second endpoint.

TECHNICAL FIELD

The subject matter described herein relates to selecting a codec pairbased on network conditions. More specifically, the subject matterrelates to methods, systems, and computer readable media for selecting acodec pair based on network conditions.

BACKGROUND

Digital communications networks employ various codecs when encoding asignal for transmission. The particular codec utilized is often afunction of the nature of the underlying information, the encodingdevice's capabilities, and the required level of quality of service(QoS). A typical digital mobile telephone handset, for example, willencode a signal using a codec that is optimized for telephoneconversations supported by the handset and capable of providing asufficient level of QoS. Ideally, the codec utilized is also compatiblewith the network hardware required to complete the call. Often, however,the codec utilized by the encoding endpoint is not supported by thedestination endpoint and/or network hardware that must be traversed enroute to the destination endpoint. For example, a call may be placedfrom an endpoint in one provider's network to an endpoint in a differentprovider's network. Each of the providers may utilize different codecsfor encoding calls. Such a scenario necessitates the use of a transcoderto decode the signal from the originating endpoint's selected codec andthen re-encode the signal using the destination endpoint's selectedcodec.

Codecs are designed with specific performance requirements in mind andtheir performance may vary dramatically based on the difference betweenthe conditions in which they were designed to operate and actualconditions. For example, while one codec may provide excellent QoS undernormal network load, its QoS may decline to unacceptable levels underdemanding network conditions. Similarly, another codec may providerelatively acceptable levels of QoS under demanding network conditions,but may fail to provide an excellent level of QoS, even under idealnetwork conditions. A provider deciding which of the two codecs toemploy may have to prioritize reliable service and, in turn, place arelatively low ceiling on the level of QoS that it is able to offer itsusers.

Accordingly, a need exists for methods, systems, and computer readablemedia for selecting a codec pair based on network conditions.

SUMMARY

According to one aspect, the subject matter described herein includes amethod for selecting a codec pair based on network conditions. Themethod includes steps occurring at a network node including a firstcommunication interface and a second communication interface. The stepsinclude obtaining a first performance metric indicating a condition of afirst network connected to the network node via the first communicationinterface, the first network including a first endpoint. The steps alsoinclude obtaining a second performance metric indicating a condition ofa second network connected to the network node via the secondcommunication interface, the second network including a second endpoint.The steps further include generating or updating a codec selection modelbased on the obtained first performance metric and the obtained secondperformance metric. The steps further include selecting a first codecfrom a plurality of codecs compatible with the first endpoint based onthe codec selection model. The steps further include selecting a secondcodec from a plurality of codecs compatible with the second endpointbased on the codec selection model. The steps further include utilizingthe first selected codec and the second selected codec to communicate aportion of a communication session between the first endpoint and thesecond endpoint.

According to another aspect, the subject matter described hereinincludes a system for selecting a codec pair based on networkconditions. The system includes a first communication interfaceconfigured to interface with a first network including a first endpoint.The system also includes a second communication interface configured tointerface with a second network including a second endpoint. The systemfurther includes a network performance module configured to obtain afirst performance metric indicating a condition of the first network anda second performance metric indicating a condition of the secondnetwork. The system further includes a codec selection module configuredto generate or update a codec selection model based on the obtainedfirst performance metric and the obtained second performance metric,select a first codec from a plurality of codecs compatible with thefirst endpoint based on the codec selection model, and select a secondcodec from a plurality of codecs compatible with the second endpointbased on the codec selection model. The system further includes atranscoder configured to utilize the first selected codec and the secondselected codec to communicate a portion of a communication sessionbetween the first endpoint and the second endpoint.

As used herein, the term “node” refers to a physical computing platformincluding one or more processors and memory.

As used herein, the terms “function” or “module” refer to software incombination with hardware (such as a processor) and/or firmware forimplementing features described herein.

The subject matter described herein can be implemented in software incombination with hardware and/or firmware. For example, the subjectmatter described herein may be implemented in software executed by oneor more processors. In one exemplary implementation, the subject matterdescribed herein may be implemented using a non-transitory computerreadable medium having stored thereon computer executable instructionsthat when executed by the processor of a computer control the computerto perform steps. Exemplary computer readable media suitable forimplementing the subject matter described herein include non-transitorycomputer readable media, such as disk memory devices, chip memorydevices, programmable logic devices, and application specific integratedcircuits. In addition, a computer readable medium that implements thesubject matter described herein may be located on a single device orcomputing platform or may be distributed across multiple devices orcomputing platforms.

BRIEF DESCRIPTION OF THE DRAWINGS

The subject matter described herein will now be explained with referenceto the accompanying drawings of which:

FIG. 1 is a network diagram illustrating an exemplary networkenvironment for selecting a codec pair based on network conditions inaccordance with embodiments of the subject matter described herein;

FIG. 2 is a block diagram illustrating an exemplary system for selectinga codec pair based on network conditions in accordance with embodimentsof the subject matter described herein;

FIG. 3 is a flow diagram illustrating an exemplary sequence forselecting a codec pair based on network conditions in accordance withembodiments of the subject matter described herein; and

FIGS. 4A and 4B are respectively a first and second portion of a flowchart illustrating an exemplary process for selecting a codec pair basedon network conditions in accordance with embodiments of the subjectmatter described herein.

DETAILED DESCRIPTION

Methods, systems, and computer readable media for selecting a codec pairbased on network conditions are provided. FIG. 1 is a network diagramillustrating an exemplary network environment for selecting a codec pairbased on network conditions in accordance with embodiments of thesubject matter described herein. Referring to FIG. 1, networkenvironment 100 may include one or more user equipment (UE) devices. Forexample, network environment 100 may include UE 102 and UE 104. UE 102and/or UE 104 may be any device capable of participating in acommunication session. For example, UE 102 and/or UE 104 may be a mobilehandset, smartphone, tablet computer, laptop computer, desktop computer,or other device capable of participating in a communication session.Network environment 100 may also include one or more networks. Forexample, network environment 100 may include access network 106, accessnetwork 108, and/or carrier network 110. A network may be anycombination of one or more nodes for supporting a communication session.For example, a network may include one or more nodes for supporting acommunication session between UE 102 and UE 104. Access network 106and/or access network 108 may be a wireless access network, such as acellular communication network and may include one or moretransceiver/receiver stations for communicating with one or more UE(s).For example, access networks 106 and 108 may be cellular communicationnetworks and may respectively include transceiver/receiver stations 112and 114 for respectively communicating with UEs 102 and 104. Carriernetwork 110 may interface access network 106 and access network 108, andmay include one or more nodes for supporting a communication sessionbetween UE 102 and UE 104. For example, carrier network 110 may includetranscoder node 116. Transcoder node 116 may be configured to transcodea portion of a communication session between UE 102 and UE 104.Transcoder node 116 may be, for example, a session border controller(SBC) and/or a media gateway (MGW). In accordance with embodiments ofthe subject matter described herein, transcoder node 116 may select acodec pair based on network conditions. For example, transcoder node 116may select a codec pair to be utilized to communicate a portion of acommunication session between UE 102 and UE 104 based on networkconditions associated with access network 106, access network 108,and/or carrier network 110.

FIG. 2 is a block diagram illustrating an exemplary system for selectinga codec pair based on network conditions in accordance with embodimentsof the subject matter described herein. Referring to FIG. 2, transcodernode 116 may include one or more communication interfaces. For example,transcoder node 116 includes communication interface 200 andcommunication interface 202. Communication interface 200 andcommunication interface 202 may be configured to interface with one ormore network(s). For example, communication interface 200 may beconfigured to interface with access network 106 and communicationinterface 202 may be configured to interface with access network 108.Communication interface 200 and communication interface 202 may be anycommunication interface capable of supporting a communication session.For example, communication interface 200 and/or communication interface202 may be a packet interface or a time-division multiplexing (TDM)interface. In some embodiments, communication interface 200 may be apacket interface and communication interface 202 may be a TDM interface.In some embodiments, communication interface 200 and communicationinterface 202 may both be packet interfaces. Communication interface 200and communication interface 202 need not consist of two distincthardware interfaces. For example, communication interface 200 andcommunication interface 202 may be different facets of a single packetinterface card, each facet interfacing with a different network (e.g.,access networks 106 and 108).

Transcoder node 116 may also include network performance module 204.Network performance module 204 may be configured to obtain one or moreperformance metric(s) indicating a condition of one or more networks.For example, network performance module 204 may be configured to obtaina performance metric indicating a condition of access network 106.Similarly, network performance module 204 may be configured to obtain aperformance metric indicating a condition of access network 108. Networkperformance module 204 may be configured to obtain one or moreperformance metrics. For example, network performance module 204 may beconfigured to obtain one or more of a measure of packet loss, a measureof end-to-end packet delay, and a measure of jitter. Network performancemodule 204 may be operative to communicate with communication interface200 and/or communication interface 202 for obtaining one or moreperformance metrics. For example, network performance module 204 and/orone or both of communication interface(s) 200 and 202 may include anetwork probe for obtaining one or more performance metrics. In someembodiments, network performance module 204 may have access to one ormore performance metrics from a probe external to transcoder node 116.For example, network performance module 204 may have access to one ormore performance metrics associated with access network 106 and/oraccess network 108 from a probe external to transcoder node 116 viacommunication interface 200 and/or communication interface 202. In someembodiments, network performance module 204 may access one or moreperformance metrics using a standardized protocol, such as real-timetransport control protocol (RTCP) or RTCP-extended reports (RTCP-XR).RTCP-XR is an extended version of RTCP which may provide access to moreextensive information regarding network conditions.

In accordance with embodiments of the subject matter described herein,transcoder node 116 may also include codec selection module 206. Codecselection module 206 may be configured to determine one or more codec(s)that are compatible with one or more endpoint(s) that utilize transcodernode 116. For example, codec selection module 206 may be configured todetermine one or more codec(s) compatible with one or more endpoint(s)in access network 106 (e.g., one or more codec(s) compatible with UE102) and/or one or more codec(s) compatible with one or more endpoint(s)in access network 108 (e.g., one or more codec(s) compatible with UE104). In some embodiments, codec selection module 206 may be configuredto determine one or more codec(s) compatible with a given endpoint basedon a session description protocol (SDP) offer message. In someembodiments, codec selection module 206 may be configured to determineone or more codec(s) compatible with a given endpoint based onpre-configured compatibility information associated with the endpoint.

As described above, codecs are designed with specific performancerequirements in mind and their performance may vary dramatically basedon the difference between the conditions in which they were designed tooperate and actual conditions. Thus, for example, while one codec mayperform well under a given set of network conditions, it may fail toprovide sufficient QoS under more demanding network conditions.Similarly, while another codec may perform adequately under a relativelywide range of network conditions, it may not perform as well underoptimal network conditions. In order to ensure service under mostconditions, providers may be forced to use the codec that performsadequately under a wide range of conditions, a decision which mayunnecessarily limit QoS under optimal conditions.

In accordance with embodiments of the subject matter described herein,codec selection module 206 may be configured to generate or update acodec selection model based on one or more network condition(s). Forexample, codec selection module 206 may be configured to generate and/orupdate a codec selection model based on one or more condition(s)associated with access network 106 and/or one or more condition(s)associated with access network 108. Codec selection module 206 may beoperatively associated with network performance module 204 for obtaininginformation related to such network conditions. For example, codecselection module 206 may obtain from network performance module 204 aperformance metric (e.g., a measure of packet loss, a measure ofend-to-end packet delay, and/or a measure of jitter) indicating acondition of access network 106. Similarly, codec selection module 206may obtain from network performance module 204 a performance metric(e.g., a measure of packet loss, a measure of end-to-end packet delay,and/or a measure of jitter) indicating a condition of access network108. As will be described in greater detail below, codec selectionmodule 206 may utilize these one or more performance metric(s) togenerate or update a codec selection model. Having generated or updatedthe codec selection model to reflect substantially current networkconditions (e.g., conditions of access network 106 and/or access network108), codec selection module 206 may select a first codec from among oneor more codec(s) determined to be compatible with an endpoint in accessnetwork 106 (e.g., UE 102) and a second codec from among one or morecodec(s) determined to be compatible with an endpoint in access network108 (e.g., UE 104) based on the generated or updated codec selectionmodel. Accordingly, a codec may be selected which is optimal for useunder substantially current network conditions in access network 106and/or access network 108. Transcoder node 116 may also includetranscoder 208. Transcoder 208 may be operative to communicate withcodec selection module 206 and thus may be informed of the selectedcodecs by codec selection module 206. Transcoder 208 may be configuredto utilize the selected codecs to communicate a portion of acommunication session between the two endpoints (e.g., a communicationsession between UE 102 and UE 104). In some embodiments, the selectedcodecs may be the same and transcoder 208 may communicate the portion ofthe communication session between the two endpoints by supporting tandemfree operation (TFO). In some embodiments, the selected codecs may bedifferent and transcoder 208 may communicate the portion of thecommunication session between the two endpoints by transcoding theportion of the communication session from the first selected codec(e.g., the selected codec compatible with UE 102) to the second selectedcodec (e.g., the selected codec compatible with UE 104).

As indicated above, in accordance with embodiments of the subject matterdescribed herein, codec selection module 206 may be configured togenerate and/or update a codec selection model based on one or morenetwork condition(s), for example, one or more network condition(s)associated with access network 106 and/or one or more networkcondition(s) associated with access network 108. In some embodiments,the codec selection model may be based on the E-model (ITU-T G.10704/2009), a well-proven computation model that predicts voice qualityusing, inter alia, one or more network characteristic(s) such as delay,jitter, and packet loss. The codec selection model may be generated fora given communication session by using substantially current networkconditions to compute an R-factor for each possible combination ofcodecs compatible with each endpoint of the communication session. Forexample, an R-factor can be computed for each combination of codecs thatare determined to be compatible with UE 102 and UE 104 based on one ormore performance metric(s) associated with access network 106 and/or oneor more performance metric(s) associated with access network 108.

An R-factor is a scalar quality rating value which varies directly withoverall conversation quality and may be obtained using the followingformula:R=Ro−Is−Id−Ie-eff+A

Where:

-   -   Ro: represents in principle the basic signal-to-noise ratio (in        narrow band, Ro is defaulted to 93.2)    -   Is: is a combination of all impairments which occur more or less        simultaneously with the voice signal    -   Id: represents the impairments caused by delay and the effective        equipment impairment factor    -   Ie-eff: represents impairments caused by low bit-rate codecs and        may also include impairment due to randomly distributed packet        loss, but may take packet distribution into account    -   A: is an advantage factor which allows for compensation of        impairment factors when there are other advantages of access to        the user        The number of performance metrics readily obtainable with        respect to a given network may be limited and the computation of        a given R-factor may be simplified to take into account such        practical limitations. For example, the following formula may be        used to compute an R-factor that takes into account delay and        jitter (without considering the effect of echo) and the effect        of packet loss:        R=93.2−Id−Ie-eff

Ie-eff corresponds to an effective equipment impairment factor thatreflects the effect of packet loss. Ie-eff may be calculated using thefollowing formula:

${{Ie}\text{-}{eff}} = {{Ie} + {( {95 - {Ie}} ) \cdot \frac{Ppl}{\frac{Ppl}{BurstR} + {Bpl}}}}$

Where:

-   -   Ie: corresponds to an equipment impairment factor    -   Ppl: corresponds to a packet loss probability    -   Bpl: corresponds to a packet loss robustness factor    -   BurstR: corresponds to a burst ratio        In some embodiments BurstR may be assumed to equal 1.0,        corresponding to a random packet loss distribution. In other        embodiments, if an accurate metric (e.g., an RTCP-XR metric) is        available, a more accurate BurstR value may be utilized. The Ie        value for an element utilizing a low bit-rate codec may depend        on opinion score test results and network experience. It may be        estimated using a predetermined model derived using        codec-specific values for the equipment impairment factor at        zero packet loss and the packet loss robustness factor, both of        which may be found in Appendix I of ITU-T G.113 (December 1998).        For example, Ie can be estimated using a predetermined model,        such as the regression-based model described by Lingfen Sun &        Emmanuel C. Ifeachor in “Voice Quality Prediction Models and        Their Application in VoIP Networks, IEEE Transactions on        Multimedia, Vol. 8, No. 4 (August 2006), which discloses a        procedure for developing regression-based models that can be        used to estimate an Ie value for a given codec at various packet        loss rates using perceptual evaluation of speech quality (PESQ).        Such a model may be developed for each codec a network component        is expected to support.

Id represents the impairment delay caused by too-long absolute delay Ta(assuming perfect echo cancelling). In some embodiments, Id may beestimated using the method described by Rix et al., “PerceptualEvaluation of Speech Quality (PESQ): The New ITU Standard for End-to-EndSpeech Quality Assessment Part I—Time-Delay Compensation”; JAES Volume50, Issue 10, pp. 755-764 (October 2002). In some embodiments, Id may beestimated using the following formulas:

For Ta≦100 ms:

-   -   Id=0

For Ta>100 ms:

${Id} = {25\{ {( {1 + X^{6}} )^{\frac{1}{6}} - {3( {1 + \lbrack \frac{X}{3} \rbrack^{6}} )^{\frac{1}{6}}} + 2} \}}$

-   -   with:

$X = \frac{\log( \frac{Ta}{100} )}{\log\; 2}$Ta may take the end-to-end delay into consideration, but also mayinclude various delays that may be incurred at the network component iftranscoding is required (i.e., if the codecs are different). Among themost important forms of delay that may be accounted for are:

-   -   Processing delay and Algorithmic Delay: the time taken by a        digital signal processor (DSP) to compress the analog signal.        Some codecs also require knowledge of future voice samples; this        is the look ahead and is referred to as algorithmic delay. Table        1 presents some typical delay characteristics for some commonly        used codecs. Table 1 should be considered with care as a network        component doing IP to IP transcoding may encounter much lower        delay if packets are processed as they are received, thereby        limiting the overall added delay to the algorithmic delay plus a        minimal delay associated with DSP processing. Delay may vary        from one implementation to another and the decision algorithm        may consider what the impact on delay is, based on network        component implementation. Whenever a codec combination requires        transcoding, Ta for both codecs may include processing and        algorithmic delay.    -   Packetization delay: In a network component located between two        IP networks this delay may generally not be encountered,        excluding cases when the packetization time (ptime) on both        network sides are different, which may require buffering. A        network component interfacing IP-TDM may experience        packetization delay. This type of delay, if experienced, may be        taken into account by Ta.    -   De-Jitter delay: As for packetization delay, de-jitter delay        would not usually be a problem in an IP-IP implementation that        triggers transcoding as real-time transport protocol (RTP)        packets are received. Some implementations may yet rely on a        jitter buffer or may face a TDM interface. In such cases, a        model estimating the effect of jitter on the jitter buffer delay        may be used and the result added to Ta.

TABLE 1 Various codecs’ characteristics Frame End user Size Look-implementation Rate (IP packet) ahead delay estimate R- Codec (Kb/s)(ms) (ms) (ms)** factor*** G.711 64 10, 20* 0 0.125 93 GSM- 12.2 20 0 4089 EFR AMR- 12.2 20 0 40 89 12.2 AMR-6.7 6.7 20 0 40 71 EVRC 8 20 10 5088 G.726 32 10, 20* 0 0.250 87 (32k) G.729 8 10 5 25 83 G.729A 8 10 5 2583 G.723.1 5.3 30 7.5 67.5 75 (5.3k) *Waveform (sample based) codecswhich do not require specific frame sizes, these numbers reflect typicalpacketization delays. **The total delay for an ordinary implementationof the codec on a DSP, based on twice the frame size plus the“look-ahead”; assumes one frame per packet. In an IP-IP networkcomponent the processing delay can be drastically reduced if packets areprocessed as they are received (limiting it to the algorithmic delayplus some DSP processing). This table is for illustrative purposes onlyand specific implementations will vary. ***Score obtained in perfectconditions (i.e., no packet loss, no noise, no delay, etc.) so this isthe best possible score for the codec.

An R-factor may be calculated for every codec combination that a networkcomponent may offer its endpoints in a given communication session. Forexample, an R-factor may be calculated for every codec combination thattranscoder node 116 may offer to UE 102 and/or UE 104. An R-factor maybe computed by calculating both Ie and Id for each codec usingsubstantially current network conditions. For example, an R-factor maybe computed for every codec combination transcoder node 116 may offer UE102 and UE 104 by transcoder node 116's codec selection module 206calculating both Ie and Id for each codec compatible with UE 102 and/orUE 104 using substantially current network conditions associated withaccess network 106 and/or access network 108. An R-factor for each codeccombination R_(c) may then be computed by entering the calculated Ie andId for each codec (e.g., Ie_(codec-a); Id_(codec-a); Ie_(codec-b); andId_(codec-b)) into the following formula:R _(c)=93.2−Id _(codec-a) −Ie _(codec-a) −Id _(codec-b) −Ie _(codec-b)The following table illustrates the type of results (i.e., R-factors)that might be obtained under near perfect conditions:

TABLE 2 Exemplary R-factors under near perfect conditions Codec 2 (e.g.,codecs compatible with UE 104) G.729 FROM/TO G.711 AMR 12.2 EVRC G.729(WO VAD) Codec 1 (e.g., G.711  93* 88 87 83 82 codecs compatible withAMR 12.2 88  88* 82 78 77 UE 102) EVRC 87 82  87* 77 76 G.729 83 78 77 83* 72 G.729 82 77 76 72  82* (WO VAD) *No transcoding (i.e., TFO).

As Table 2 illustrates, an R-factor may be calculated for each codeccombination. This will result in a total of N*M R-factors, where N isthe total number of codecs compatible with the first endpoint (e.g., UE102) and M is the total number of codecs compatible with the secondendpoint (e.g., UE 104). A codec combination may be selected by choosingthe combination with the greatest R-factor value.

In some embodiments, the codec selection model may take one or morefactor(s) other than voice quality into account. For example, the codecselection model may take bandwidth and/or least cost routing intoaccount. In some embodiments, the codec selection model may assign aweight to each of multiple factors, taking each of the factors intoaccount to the extent of its weight. In such embodiments, the followingformula may be utilized:

${Dc} = {\sum\limits_{n = 0}^{N - 1}\;{{w(n)} \cdot {s(n)}}}$

Where:

-   -   N: corresponds to the total number of factors    -   Dc: corresponds to the decision factor for combination c (the        higher the factor the better the combination)    -   w(n): corresponds to the weight given each factor (for example,        the sum of all weights may total to 1.0)

${\sum\limits_{n = 0}^{N - 1}\;{w(n)}} = 1$

-   -   s(n): corresponds to the prorated quantitative value of factor        n, using the best possible result (BR) in all combinations        considered as the basis for comparison to the current        combination (CR), and brought back on a scale of 100        -   If BR≧CR:

${s(n)} = {( \frac{CR}{BR} ) \times 100}$

-   -   -   If CR>BR:

${s(n)} = {( \frac{BR}{CR} ) \times 100}$For example:

-   -   If bandwidth usage and voice quality are both weighted at fifty        percent.    -   For codec combination 1 (c₁):        -   R-factor=90        -   Average bandwidth usage=64K    -   For codec combination 2 (c₂):        -   R-factor=80        -   Average bandwidth usage=10K    -   In both cases w(1)=0.5 and w(2)=0.5    -   For codec combination 1 (c₁):

${s(1)} = {{( \frac{10}{64} ) \times 100} = 15.7}$${s(2)} = {{( \frac{90}{90} ) \times 100} = 100}$ Dc₁ = 57.85

-   -   For codec combination 2 (c₂):

${s(1)} = {{( \frac{10}{10} ) \times 100} = 100}$${s(2)} = {{( \frac{80}{90} ) \times 100} = 88}$ Dc₂ = 94.0

-   -   Thus, codec combination 2 may be favored.

FIG. 3 is a flow diagram illustrating an exemplary sequence forselecting a codec pair based on network conditions in accordance withembodiments of the subject matter described herein. Referring to FIG. 3,communication session 300 may exist or may be in the process of beingsetup between UE 102 and UE 104. UE 102 and UE 104 may not both utilizea common codec, or one or more intervening network node(s) between UE102 and UE 104 may not be compatible with a codec utilized by one orboth of UE 102 and UE 104, and thus transcoding of a portion ofcommunication session 300 may be required. In accordance withembodiments of the subject matter described herein, the codecs utilizedmay be selected based on network conditions, for example, networkconditions in one or more of access network 106 and access network 108.At step 1, transcoder node 116's network performance module 204 mayrequest a performance metric from a network probe located in accessnetwork 106. At step 2, the network probe located in access network 106may respond with the requested performance metric. At step 3, transcodernode 116's network performance module 204 may request a performancemetric from a network probe located in access network 108. At step 4,the network probe located in access network 108 may respond with therequested performance metric. At step 5, transcoder node 116's codecselection module 206 may generate and/or update a codec selection modelbased on the performance metric obtained from the network probe locatedin access network 106 and the performance metric obtained from thenetwork probe located in access network 108. At step 6, transcoder node116's codec selection module 206 may select, based on the codecselection model, a first codec compatible with UE 102 and a second codeccompatible with UE 104. At step 7, transcoder node 116's transcoder 208may utilize the first selected codec (e.g., a codec compatible with UE102) and the second selected codec (e.g., a codec compatible with UE104) to communicate a portion of communication session 300 between UE102 and UE 104. For example, if the first selected codec and the secondselected codec are the same, transcoder node 116's transcoder 208 maycommunicate a portion of communication session 300 by supporting TFO forthe portion of communication session 300. On the other hand, if thefirst selected codec and the second selected codec are different,transcoder node 116's transcoder 208 may communicate a portion ofcommunication session 300 by transcoding the portion from the firstselected codec (e.g., the selected codec compatible with UE 102) to thesecond selected codec (e.g., the selected codec compatible with UE 104).

In some embodiments, transcoder node 116 may perform codec selectionbased on network conditions, as represented by the codec selectionmodel, only once when communication session 300 is setup. In otherembodiments, transcoder node 116 may perform codec selection based onnetwork conditions, as represented by the codec selection model, atsetup and/or periodically, updating the selected codecs based onpotentially changing network conditions. In some embodiments, transcodernode 116 may update the codec selection model and/or select a new codeccombination periodically at predefined intervals (e.g., every 30seconds). In some embodiments, transcoder node 116 may update the codecselection model and/or select a new codec combination based on ahysteresis loop so that a transition will occur only when a differentcodec combination would increase QoS by a predefined margin (e.g., fivepercent), thereby reducing potentially constant transitions that mightinterfere with overall QoS. In some embodiments, codec renegotiation maybe performed by ordering the codecs specified in SDP messages by theircorresponding R-factor values. In some embodiments, codecnegotiation/renegotiation may be performed in accordance with RFC 5939(September 2010).

FIGS. 4A and 4B are respectively a first and second portion of a flowchart illustrating an exemplary process for selecting a codec pair basedon network conditions in accordance with embodiments of the subjectmatter described herein. The steps may be performed at a network nodeincluding a first communication interface and a second communicationinterface. For example, the steps may be performed at transcoder node116 which may include communication interface 200 and communicationinterface 202. Referring to FIG. 4A, in step 400, a first performancemetric indicating a condition of a first network connected to thenetwork node via the first communication interface is obtained, thefirst network including a first endpoint. For example, transcoder node116's network performance module 204 may obtain a first performancemetric indicating a condition of access network 106. Access network 106may include a first endpoint (e.g., UE 102) and may be connected totranscoder node 116 via communication interface 200. In step 402, asecond performance metric indicating a condition of a second networkconnected to the network node via the second communication interface isobtained, the second network including a second endpoint. For example,transcoder node 116's network performance module 204 may obtain a secondperformance metric indicating a condition of access network 108. Accessnetwork 108 may include a second endpoint (e.g., UE 104) and may beconnected to transcoder node 116 via communication interface 202. Instep 404 a codec selection model is generated or updated based on theobtained first performance metric and the obtained second performancemetric. For example, transcoder node 116's codec selection module 206may generate or update a codec selection model based on the obtainedfirst performance metric indicating a condition of access network 106and the obtained second performance metric indicating a condition ofaccess network 108. Referring to FIG. 4B, in step 406, a first codec isselected from a plurality of codecs compatible with the first endpointbased on the codec selection model. For example, transcoder node 116'scodec selection module 206 may select a codec from a plurality of codecscompatible with UE 102 based on the codec selection model. In step 408,a second codec is selected from a plurality of codecs compatible withthe second endpoint based on the codec selection model. For example,transcoder node 116's codec selection module 206 may select a codec froma plurality of codecs compatible with UE 104 based on the codecselection model. In step 410, the first selected codec and the secondselected codec are utilized to communicate a portion of a communicationsession between the first endpoint and the second endpoint. For example,a portion of communication session 300 between UE 102 and UE 104 may betranscoded by transcoder node 116's transcoder 208 from the firstselected codec to the second selected codec.

It will be understood that various details of the subject matterdescribed herein may be changed without departing from the scope of thesubject matter described herein. Furthermore, the foregoing descriptionis for the purpose of illustration only, and not for the purpose oflimitation, as the subject matter described herein is defined by theclaims as set forth hereinafter.

What is claimed is:
 1. A method for selecting a codec pair based onnetwork conditions, the method comprising: at a network node including afirst communication interface and a second communication interface:obtaining a first performance metric indicating a condition of a firstnetwork connected to the network node via the first communicationinterface, the first network including a first endpoint; obtaining asecond performance metric indicating a condition of a second networkconnected to the network node via the second communication interface,the second network including a second endpoint; modifying a firstimpairment value for the first network connection according to the firstperformance metric; modifying a second impairment value for the secondnetwork connection according to the second performance metric;generating or updating a codec selection model based on at least one ofprocessing delay, algorithmic delay, and buffering delay and based onthe first impairment value modified by the obtained first performancemetric and the second impairment value modified by the obtained secondperformance metric; selecting a first codec from a plurality of codecscompatible with the first endpoint based on the codec selection model;selecting a second codec from a plurality of codecs compatible with thesecond endpoint based on the codec selection model; and utilizing thefirst selected codec and the second selected codec to communicate aportion of a communication session between the first endpoint and thesecond endpoint.
 2. A method for selecting a codec pair based on networkconditions, the method comprising: at a network node including a firstcommunication interface and a second communication interface: obtaininga first performance metric indicating a condition of a first networkconnected to the network node via the first communication interface, thefirst network including a first endpoint; obtaining a second performancemetric indicating a condition of a second network connected to thenetwork node via the second communication interface, the second networkincluding a second endpoint; modifying a first impairment value for thefirst network connection according to the first performance metric;modifying a second impairment value for the second network connectionaccording to the second performance metric; generating or updating acodec selection model based on the first impairment value modified bythe obtained first performance metric and the second impairment valuemodified by the obtained second performance metric and based on aplurality of factors, at least one of the factors corresponding toavailable bandwidth or least cost routing, each of the factors assigneda weight and generating or updating the codec selection model includestaking into account each of the factors to the extent of its assignedweight; selecting a first codec from a plurality of codecs compatiblewith the first endpoint based on the codec selection model; selecting asecond codec from a plurality of codecs compatible with the secondendpoint based on the codec selection model; and utilizing the firstselected codec and the second selected codec to communicate a portion ofa communication session between the first endpoint and the secondendpoint.
 3. The method of claim 1 wherein generating or updating thecodec selection model includes computing a scalar value that correspondsto conversation quality for each combination of the plurality of codecscompatible with the first endpoint and the plurality of codecscompatible with the second endpoint.
 4. The method of claim 1 wherein atleast one of the first performance metric and the second performancemetric corresponds to at least one of a measure of packet loss, ameasure of end-to-end packet delay, and a measure of jitter.
 5. Themethod of claim 1 wherein at least one of the plurality of codecscompatible with the first endpoint and the plurality of codecscompatible with the second endpoint is obtained as part of a sessiondescription protocol (SDP) offer message.
 6. The method of claim 1wherein the first communication interface is a packet interface and thesecond communication interface is a packet interface.
 7. The method ofclaim 1 wherein the first communication interface is a packet interfaceand the second communication interface is a time-division multiplexing(TDM) interface.
 8. The method of claim 1 wherein the network nodecomprises at least one of a session border controller (SBC) and a mediagateway.
 9. The method of claim 1 wherein the first selected codec andthe second selected codec are different; and wherein utilizing the firstselected codec and the second selected codec to communicate the portionof the communication session between the first endpoint and the secondendpoint comprises transcoding, from the first selected codec to thesecond selected codec, the portion of the communication session betweenthe first endpoint and the second endpoint.
 10. The method of claim 1wherein the first selected codec and the second selected codec are thesame, and wherein utilizing the first selected codec and the secondselected codec to communicate the portion of the communication sessionbetween the first endpoint and the second endpoint comprises supportingtandem free operation (TFO) for the portion of the communication sessionbetween the first endpoint and the second endpoint.
 11. A system forselecting a codec pair based on network conditions, the systemcomprising: a first communication interface configured to interface witha first network including a first endpoint; a second communicationinterface configured to interface with a second network including asecond endpoint; a network performance module configured to obtain afirst performance metric indicating a condition of the first network anda second performance metric indicating a condition of the secondnetwork; a codec selection module configured to generate a codecselection model based on the obtained first performance metric and theobtained second performance metric, select a first codec from aplurality of codecs compatible with the first endpoint based on thecodec selection model, and select a second codec from a plurality ofcodecs compatible with the second endpoint based on the codec selectionmodel, and update the codec selection model during a call in response toa change in the first performance metric or the second performancemetric during the call; and a transcoder configured to utilize the firstselected codec and the second selected codec to communicate a portion ofa communication session between the first endpoint and the secondendpoint.
 12. The system of claim 11 wherein the codec selection moduleis configured to generate or update the codec selection model bycomputing a scalar value that corresponds to conversation quality foreach combination of the plurality of codecs compatible with the firstendpoint and the plurality of codecs compatible with the secondendpoint.
 13. The system of claim 11 wherein the codec selection modelis based on at least one of processing delay, algorithmic delay, andbuffering delay.
 14. The system of claim 11 wherein the codec selectionmodel is based on a plurality of factors, at least one of the factorscorresponding to available bandwidth or least cost routing.
 15. Thesystem of claim 14 wherein each of the factors is assigned a weight andwherein the codec selection module is configured to generate or updatethe codec selection model by taking into account each of the factors tothe extent of its assigned weight.
 16. The system of claim 11 wherein atleast one of the first performance metric and the second performancemetric corresponds to at least one of a measure of packet loss, ameasure of end-to-end packet delay, and a measure of jitter.
 17. Thesystem of claim 11 wherein at least one of the plurality of codecscompatible with the first endpoint and the plurality of codecscompatible with the second endpoint is obtained as part of a sessiondescription protocol (SDP) offer message.
 18. The system of claim 11wherein the first communication interface is a packet interface and thesecond communication interface is a packet interface.
 19. The system ofclaim 11 wherein the first communication interface is a packet interfaceand the second communication interface is a time-division multiplexing(TDM) interface.
 20. The system of claim 11 wherein the memory, thefirst communication interface, the second communication interface, thenetwork performance module, the codec selection module, and thetranscoder comprise a network node, and wherein the network nodecomprises at least one of a session border controller (SBC) and a mediagateway.
 21. The system of claim 11 wherein the first selected codec andthe second selected codec are different; and wherein the transcoder isconfigured to transcode, from the first selected codec to the secondselected codec, the portion of the communication session between thefirst endpoint and the second endpoint.
 22. The system of claim 11wherein the first selected codec and the second selected codec are thesame, and wherein the transcoder is configured to support tandem freeoperation (TFO) for the portion of the communication session between thefirst endpoint and the second endpoint.
 23. A method for selecting acodec pair based on network conditions, the method comprising: at anetwork node including a first communication interface and a secondcommunication interface: obtaining a first performance metric indicatinga condition of a first network connected to the network node via thefirst communication interface, the first network including a firstendpoint; obtaining a second performance metric indicating a conditionof a second network connected to the network node via the secondcommunication interface, the second network including a second endpoint;modifying a first impairment value for the first network connectionaccording to the first performance metric; modifying a second impairmentvalue for the second network connection according to the secondperformance metric; generating or updating a codec selection model basedon the first impairment value modified by the obtained first performancemetric and the second impairment value modified by the obtained secondperformance metric; selecting a first codec from a plurality of codecscompatible with the first endpoint based on the codec selection model;selecting a second codec from a plurality of codecs compatible with thesecond endpoint based on the codec selection model; utilizing the firstselected codec and the second selected codec to communicate a portion ofa communication session between the first endpoint and the secondendpoint; and updating the codec selection model during a call, inresponse to a change in the first impairment value or the secondimpairment value.